Oracle压缩黑科技（一）—基础表压缩
原文链接 https://www.red-gate.com/simple-talk/sql/oracle/compression-oracle-basic-table-compression/
译者 周天鹏
在关于Oracle压缩的这一系列文章中，我们会研究下传统Oracle数据库系统的各类压缩方式，这意味着该系列文章的目录结构大概是：
1. 基础表压缩
2. OLTP表压缩
3. 索引压缩
但是，不讨论Exadata的hybrid columnar compression (HCC)。
在这三种压缩技术中，索引压缩和基础表压缩是产品自带的核心组件，但是，OLTP压缩需要独立的“Advanced Compression Option (ACO)” license授权。再第一篇文章中，我们先用基础表压缩造一些数据，把对数据更新删除的问题留到第二篇文章中，最后基于前两篇的铺垫，我们再研究下OLTP的压缩。索引压缩单独留在第四、第五篇中探讨。
本文主要目的是解答一些关于表压缩相关的经常被问到的问题。
基础表压缩何时起作用？
人们经常问道，“我如何造压缩数据”，“Oracle如何解压这些数据块”，“压缩对性能会造成什么影响”，还有一个人们在使用任何新特性前都会问的问题“有啥不为人知的副作用吗？”
回答第一个问题最简单的方法就是通过一个实际例子。这里有5条SQL，跑完后我们先收集表的统计信息，然后查一下表里有多少数据块和一些其他相当信息。
-- 1. Baseline CTAS
create table t1
as
select * from all_objects where rownum <= 50000;
-- 2. CTAS with basic compression enabled
create table t1 compress basic
as
select * from all_objects where rownum <= 50000;
-- 3. Normal insert into empty table defined as compressed
create table t1 compress basic
as
select * from all_objects where rownum = 0;
insert into t1 select * from all_objects where rownum <= 50000
-- 4. Direct path insert into empty table defined as compressed
create table t1 compress basic
as
select * from all_objects where rownum = 0;
insert /*+ append */ into t1 select * from all_objects where rownum <= 50000
-- 5. CTAS without compression, then change to compressed
create table t1
as
select * from all_objects where rownum <= 50000;
alter table t1 compress basic;
alter table t1 move
每一条SQL执行完我都会运行下面的SQL查询数据块的信息：
select blocks, pct_free , compression, compress_for
from user_tables
where table_name = 'T1';
当然也有其他方法，我们可以将表空间定义为压缩的，这样在里面创建的所有表就会被默认进行压缩；我们还可以将分区表的分区或者子分区进行压缩；我们甚至可以将分区表定义为默认压缩，这样新增的分区就都是压缩的了。
我用下面这个图表总结了上述sql代码的结果：
test5有两个结果，一个是alter table move之前的，一个是之后的
当我在CTAS(create table as select)加了压缩选项时, Oracle自动将pctfree置为0 —— 这将数据块的数量显著减少，只用了189个数据块。pctfree为0意味着Oracle认为这张表将会变成read only的。但是，pctfree当然也可以设置为一个非空的值，这在后面的章节会讲。
在第三第四个测试中，我创建了一个启用了压缩的空表，然后插入数据。正如你所看到的，只有使用direct path insert，插入的数据才会被压缩。普通的insert操作并不会压缩数据。（insert后的数据块644个，相比CTAS 714个要少一些的原因是因为pctfree从10变为了0）
最后一个测试告诉我们，将表从非压缩改为压缩之后，对现存的数据并没有影响。如果你想将未压缩的数据进行压缩，需要先改变表的定义，然后move表。但是，move后需要立即重建表上的所有索引。
压缩原理并非如我们所想
Oracle如何进行压缩的呢？实际上，Oracle并不会进行压缩。他做的仅仅是块级别的深度复制。想象一下，你在一个数据块里有下面三行数据：
(‘XXXX’, ‘abcdef’, 254.32, ‘CLOSED’)
(‘XXXX’, ‘pqrstu’, 17.12, ‘CLOSED’)
(‘AAAA’, ‘abcdef’, 99.99, ‘CLOSED’)
Oracle会发现‘XXXX’出现了两次，‘abcdef’出现了两次，‘CLOSED’出现了三次。这样，就可以用这个块里重复的值创建一个字典表。压缩后的数据如下
T1 (‘XXXX’)
T2 (‘abcdef’)
T3 (‘CLOSED’)
(T1, T2, 254.32, T3)
(T1, ‘pqrstu’, 17.12, T3)
(‘AAAA’, T2, 99.99, T3)
其实，Oracle比这还要聪明，它可以重新排列块中的字段顺序，使得多个字段可以用一个标志代替。在我们的例子中，三行数据都有T1和T3。Oracle可以重排列这些字段，让这些标志尽可能的在一块，以至于可以用创建一个标志来代替两个标志的组合。最终数据会变成这样：
T1 (‘XXXX’, T2) -- 这是一个由数值和标志组合成的标志
T2 (‘CLOSED’)
T3 (‘abcdef’)
(T1, T3, 254.32) -- 注意这行只有了三列
(T1, ‘pqrstu’, 17.12) -- 同上
(‘AAAA’, T2, T3, 99.99)
让我们通过dump数据块里的数据来更进一步观察压缩的内部实现原理。这里是一个压缩表中的数据块中的第一个片段：
perm_9ir2[4]={ 2 0 1 3 }
这个表有4个数据块，但是对于这个块，Oracle重新排列了字段的顺序，意思是：字段0放在了第二位，字段1在第三位，字段2在第一位，字段3在第四位。
0x24:pti[0] nrow=65 offs=0
0x28:pti[1] nrow=400 offs=65
如上，这是数据块里的两个“表”，第一个是存放标志的“表”（其实就是字典表），有65个标志，在块的行目录中从0开始。第二个是真正的“表”，有400行，在块的行目录中从65开始。这意味着这个块的行目录一共有465个条目。
如果我们从第二个“表”（真正的数据表，而不是字典表）开始看，我们会发现这和普通的堆表中的数据块dump出来的一行没什么两样。但这里有一些特殊的点需要注意。
tab 1, row 0, @0x1b28
tl: 5 fb: --H-FL-- lb: 0x0 cc: 4
col 0: [ 4] 41 41 41 41
col 1: [10] 41 41 41 41 41 41 41 41 41 41
col 2: [ 2] c1 02
col 3: [10] 20 20 20 20 20 20 20 20 20 31
bindmp: 2c 00 01 04 31
基于列的长度（方括号中的数据），行的长度是26个字节（4+10+2+10），加上四个列4个字节 和 flag byte(fb:),lock byte(lb:),column count(cc:)每个1字节 - 但总的实际长度（tl:）只有5字节。而且最后一行也展示了这5个字节实际的数据。这5个字节分别是flag byte (0x2c = ‘–H-FL’), lock byte和存储的列数量。然后剩下2字节告诉我们有一个列是一个标志代表4个连续的值，而且我们需要到字典表中找0x31号标志。接下来让我们看下字典表中的49行（0x31）：
tab 0, row 49, @0x1ed0
tl: 19 fb: --H-FL-- lb: 0x0 cc: 4
col 0: [ 4] 41 41 41 41
col 1: [10] 41 41 41 41 41 41 41 41 41 41
col 2: [ 2] c1 02
col 3: [10] 20 20 20 20 20 20 20 20 20 31
bindmp: 00 08 04 36 40 ca c1 02 d2 20 20 20 20 20 20 20 20 20 31
这个标志看起来几乎和行一样 - 但是标志的总长是19字节。所以我们看下dump出来的数据。前两个字节告诉我们这个标志在这个块里用了8次。下一个字节告诉我们标志中有4个列，通过一些编码，剩下的两个字节告诉我们这个标志的前两个字段的值实际存储在在0x36(54)和0x40(64)号标志中。后两个字段直接就是实际的数据了。
所以，通过我们的方法，从行目录到行、标志，我们可以扩展一个5字节的条目到一个完整的26字节的行。
通过我们对数据块dump出的数据进行跟踪，这里还有许多知识值得学习。
1. Oracle不会解压这些数据，他只是根据你的需求，用字典表和数据表中的数据将行重构出来。
2. 重构行的时候很可能会消耗一些额外的CPU，在做全表扫描时将尤为明显。
3. 有一个副作用，为了能重构行，Oracle必须持有某些块一段时间。所以你可能发现你的sql很少发生“consistent gets – examination”的等待，因为大部分时间花在了“cache buffers chains”的latch上面。
总 结
依然有很多关于压缩的副作用值得一提，尤其是删除和更新表的时候，这也讲引导着我们去实现OLTP的压缩 - 将来的文章会讲。
我们从这第一篇文章中发现看到了：
1. 基础压缩只有在direct path inserts时有效，普通的DML不会压缩数据。
2. Oracle会默认把压缩表的PCTFREE置为0，这也很好的表明，Oracle认为建表后你不会再修改数据。
3. 基础表压缩仅仅是把重复的值进行深度复制，但Oracle足够聪明来最小化数据占用的空间。
4. 这种深度复制机制意味着Oracle不需要解压数据，只需要把块cache在buffer cache中然后在PGA里重构行即可，该操作属于CPU密集型。
相关链接
杭州沃趣科技股份有限公司创建于2012年（股票代码：839849），是一家专注为企业用户提供基于高性能、高可用、可扩展的开放数据库云平台解决方案的国产厂商。公司创始团队为原阿里巴巴数据库及运维团队核心骨干，凭借丰富的运维经验，为行业客户提供数据库云产品及软硬件一体化解决方案。
公司产品已广泛应用于证券、保险、医疗、广电传媒、银行、电信、能源电力、快递物流、公共事业、大型企业等，为这些行业用户持续提供行业解决方案及服务支持。
公司先后获得国家级高新技术企业、杭州市高新技术企业、杭州高新区瞪羚企业等称号，并设有杭州市安全可控数据库技术研发中心。公司总部位于杭州，同时在北京、上海、广州、南京、兰州建立了分支机构，拥有辐射全国的销售和服务体系。
我们始终坚信，数据是驱动企业创新的源动力！坚持围绕企业数据库做好一件事
——让高性能触手可及！